home *** CD-ROM | disk | FTP | other *** search
- Frequently Asked Questions about base-files
- ===========================================
-
- * Questions about /etc/issue and /etc/debian_version:
-
- Q. I upgraded my system to the testing distribution and now my /etc/issue
- says "wheezy/sid". Should it not read "wheezy" or "testing"?
-
- Q. I upgraded my system to the unstable distribution and now my /etc/issue
- says "wheezy/sid". Should it not read "sid" or "unstable"?
-
- A. You obviously do not understand how the testing distribution works.
- Packages uploaded for unstable reach testing after ten days, provided
- they are built for every released architecture, have no RC-bugs and
- their dependencies may be met in testing. You should consider the
- testing and unstable distributions as two sides of the same coin.
- Since the base-files package in testing was initially uploaded for
- unstable, the only sensible /etc/issue to have is one that is both
- valid for testing and unstable, hence "wheezy/sid" (or whatever is
- appropriate).
-
- Q. Why "wheezy/sid" and not "testing/unstable" as it used to be?
-
- A. The codename is a little bit more informative, as the meaning of
- "testing" changes over time.
-
- Q. Ok, but how do I know which distribution I'm running?
-
- A. If you are running testing or unstable, then /etc/debian_version is
- not a reliable way to know that anymore. Looking at the contents of
- your /etc/apt/sources.list file is probably a much better way.
-
-
- * Other questions:
-
- Q. After upgrading my system recently, I noticed that some files from
- base-files do not match the ones which are installed on a fresh install
- of squeeze. Should I not be warned about that?
-
- A. Those files are configuration files, so they are completely under
- the control of the system admin. The files installed by base-files are
- just defaults. Changes in the default files are not important enough
- to warn the user, as it is also policy that prompting should be
- reduced to a minimum. This is also the reason they are not handled via
- dpkg's conffile mechanism.
-
- In either case, if you want to "upgrade" those files, just look at the
- postinst for base-files (i.e. /var/lib/dpkg/info/base-files.postinst)
- and you will see how they are created and where their master copies are:
-
- install_from_default /usr/share/base-files/nsswitch.conf /etc/nsswitch.conf
- install_from_default /usr/share/base-files/dot.profile /root/.profile
- install_from_default /usr/share/base-files/dot.bashrc /root/.bashrc
- install_from_default /usr/share/base-files/profile /etc/profile
- install_from_default /usr/share/base-files/motd /etc/motd
-
- So, if you want your system to be as similar as possible to a newly
- installed squeeze system, you might want to sync these files manually.
-
-
- Q. Why isn't license "foo" included in common-licenses?
-
- A. I delegate such decisions to the policy group. If you want to
- propose a new license you should make a policy proposal to modify the
- paragraph in policy saying "Packages distributed under the UCB BSD
- license, Artistic license, GNU GPL and GNU LGPL should refer to the
- files in /usr/share/common-licenses". The way of doing this is
- explained in the debian-policy package. As usual, you should always
- take a look at already reported bugs against debian-policy before
- submitting a new one.
-
- Q. I upgraded from woody to sarge. Should my system be FHS-compliant now?
-
- A. Achieving FHS compliance by upgrading would be tricky and prone to
- error in certain cases, so it is not a goal of base-files, nor it is
- planned to be. By default, some "mandatory" directories (like /opt,
- /srv or /media) are only created in the first install (performed by
- debootstrap), to keep the code as simple as possible, follow the
- principle of least surprise on upgrades, and also to give people the
- freedom to remove those directories without them being created again
- when base-files is upgraded. Therefore, if you are running any sort of
- compliance tests, you should do it on newly installed systems only.
-
-
- Santiago Vila <sanvila@debian.org>
-